The present invention relates generally to computing systems that allow multiprocessing, specifically, the invention relates to a method that allows processes to be terminated by other processes, particularly in multi-threaded environments.
When a number of processes are concurrently executing in a multiple process environment a need can arise to force termination of one or more of those processes. For example, a process may "hang," i.e., experience an error that causes it to halt without terminating, or to enter an endless loop. In such instances it is desirable to end the errant process rather halt all processes and bring down the entire system. Thus, operating system functions are provided that allow a process to terminate another process.
The process need not necessarily be errant. There may also be instances, such as a panic shutdown, to halt or otherwise terminate a process. However, if the process requested or desired to be terminated is, at the time the request or desire is acted upon, performing some system critical operation (e.g., performing a write to (disk) storage), there is a chance that system data or a database or some other data structure can be corrupted. For this reason processes are often given the opportunity to prohibit being stopped until a system critical operation has completed.
When it is wanted to "port" such processes to other environments, problems concerning the capability of allowing a process to stop another process are encountered. Application programs are normally written to create processes that run on specific systems and in conjunction with a specific operating system that performs supervisory control of system resource allocation (e.g., allocation and usage of such system resources as memory, processing time, disk space, peripheral devices, and the like). Use of these processes over time verifies their credibility and operability. The more useful processes become the objects of "porting," i.e., the transfer of the programs to an operating system different from that application originally intended. This will typically require that the application program be rewritten for the new operating system, and if the new operating system is substantially different, or the program language in which the process was originally developed is particularly difficult for the new operating system, the porting task can become a tedious. Such porting procedures can, therefore, be time consuming and expensive, depending upon the process, the structure of the old and new operating systems, and other reasons not necessarily relevant here. For this reason, it may be desirable to simulate the old operating system in the new operating system environment so that the process being ported does not need to be substantially revised--if at all.
However, simulating an operating system in order to allow porting of a process or processors may carry with it additional problems. One such problem concerns the necessary cleanup of system resources (e.g., removal of data structures, deallocation of memory, etc.) obtained by a process while running. For example, normally an operating system controls the "stack" (i.e., that data structure used by the operating system to contain status data for running processes), and the cleanup of a process is done by the process that is terminating by calling a re-entrant routine that uses services of the operating system and its access to the stack. However, when a process has been ported from a foreign operating system environment to run in conjunction with a simulated version of the foreign operating system (hereinafter "Simulated Operating System" or "SOS") the usual cleanup most likely will not be available in the present or "native" operating system on which the Simulated Operating System runs. Also, there may be code in the Simulated Operating System that would be beneficial to use in the Native Operating System environment.
Porting to other operating systems also created problems in connection with process stopping--particularly in distributed and/or multi-thread environments. For example, suppose process A wishes to stop process B. The stop request will be sent to the service of the simulated operating system which will check the stop mode of the target process, process B (i.e., whether it has made itself unstoppable in order that it complete some system critical task). If the check indicates the process is stoppable, the service will spawn a thread that, in turn, will attempt to stop the target process. But, there is a chance that a thread of the target process raises the stop mode of the target process in order to create a system critical task before the service completes its task of stopping the target process. Thus, the target process will either be stopped in the midst of a task, resulting in possible data corruption, or the target process will continue while the process A believes it has stopped.
It can be seen therefore, that a technique for allowing one process, running in a multiprocess and/or, in particular, a multi-threaded environment, to terminate another process even if the process to be terminated is running in an unstoppable mode.